The achievable service quality of an Internet access network is contingent on the network connection's available bit rate (i.e., bandwidth). Services such as Voice over Internet Protocol (VoIP), video streaming or videoconferencing, on-line gaming, or other “time-sensitive” applications, referred to as real-time applications, require bandwidth at a specific rate for acceptable performance. Conventional solutions to measuring bit rate only measure an average bit rate over time. But because available bandwidth is constantly varying in a network connection at any given point in time due to drastically changing network conditions, conventional methods that only measure the average bit rate over a period of time are inadequate. In addition, to perform the average bit rate measurement, conventional methods require external servers and multiple data packets.
Conventional methods of speed test measurements, generally known to the public, use servers located in the Internet. Network test packets, which are issued by the requestor, commonly must traverse a number of intermediate nodes before arriving at the speed test server. In such methods, the supposed speed measurement is, in practice, at best merely a measure of the slowest link speed, and not necessarily the actual speed of the requestor's direct connection. A major disadvantage of this conventional speed test approach is that it is not useful for specifying service levels for Quality of Service, which requires a guaranteed available bandwidth, since Internet packets are transmitted on a “best effort” basis and may traverse various nodes that have varying link speeds.
Known conventional methods for acquiring connection bit rate estimates include: (1) interrogating the Internet Service Provider (“ISP”), or (2) interrogating the access modem directly, or (3) manually entering the likely bandwidth at the user premises equipment, or (4) running bit rate estimation algorithms using Internet Control Message Protocol (ICMP) (“Pings”) or Transmission Control Protocol (TCP) echo requests with a server, or (5) running a rate estimation algorithm based on real-time traffic. The primary disadvantages of these methods, respectively, are: (1) bit rate information is, in practice, not available from an ISP, or (2) bit rate measurement and reporting is not a feature of today's Internet access modems, or (3) manual settings, even when updated periodically, cannot reflect rapidly changing conditions on the network, or (4) rate estimation algorithms provide time-averaged estimates (that is, non-instantaneous estimates.)
Conventional methods are also generally intrusive, require user invocation, and cannot provide the rapid speed measurements necessary to secure fast, error-free, network-efficient connections per session. Other methods include using timestamps in packets to determine network bandwidth, but these methods cannot account for the clock skew of each of the devices at the various hops on the network that a packet must traverse through. Methods using satellites have been tried to account for this clock skew problem, but these approximation methods encounter many additional problems.